切勿盲目崇拜微服务！
作者简介：Stavros Korokithakis是希腊人，单身父亲，是个技术爱好者和业余F1方程式赛车手，创办了StochasticTechnologies这家软件开发公司。
微服务是很出色。这个谁都知道，因为最近种种成功故事在到处盛传。新闻媒体在竞相报道这样的故事，说什么人们拿来庞大的单一整体式代码库（monolithic codebase）后对它们进行分解，然后添加HTTP应用编程接口（API），就能享用所有好处。
与所有时髦的做法一样，微服务是不知不觉中开始兴起来的，有人尝试它，发现效果对他们来说很好，于中他们兴致勃勃地列举这种新做法具有的种种优点，大家都难抑激动心情，渴望尝试一下。很快，一堆文章都在夸它的效果多好多好、更多的人试过后卓有成效。不过，你没有听到的是它在哪些情况或场合下不行，就因为人们没有同样大的劲头来讲述自个的失败故事。
我在继续探讨这篇文章之前想澄清一点，我倒不是说微服务不行。与每项技术一样，微服务有其优点，也有其缺点，所以我要稍微详细地介绍缺点，因为前者已经报道得够多的了。
到现在为止，你恐怕听说过“货物崇拜”（cargo cult）这个短语。这个比喻是指，别人做成功了，你也跟着做些事，试图同样取得成功，不过这些事与成功毫无关系，本身也不足以成功。
具体到本文而言，这是指实施微服务，因为所有赶时髦的人都在搞微服务，却没有考虑它到底是否合适，也没有首先实际做一些确保微服务成功的事情。与其他任何工具一样，在你使用微服务之前，有必要知道微服务的优点和缺点。
我们先来说说优点。
可扩展性：这是一大优点。因为微服务是很小的独立式服务，如果需要，可以将它们放到各自的服务器上。你可以以一种对应用程序来说合理的方式，对微服务进行负载均衡、切分或配置。
你还可以根据每个服务来决定将数据存储在哪里，使用对每一种使用场合来说最合理的数据存储区（甚至编程语言或技术）。
更洁净的架构：每个服务都有明确定义的边界，边界通常不可侵犯。因方便而访问私有数据的日子已经一去不复返了，现在每个服务都在API后面清楚地分开来，根本没有别的东西可以访问。
独立部署：由于每个服务是分开的，很容易根据需要来部署它们，甚至一天可以部署多次。这也有助于延长正常运行时间。
更小的代码库：由于代码库更小，理解起来也更容易了。每个服务的目的明确定义，服务的接口也是如此，所以某人迅速读取和理解服务，因而修改、扩展和维护服务就要容易得多。
复杂性：你立即使服务器需要做的事情增加了十倍。你径直在当中插入了好几层，在你的堆栈里面搭建起了一个网络，大大增加了总的部署和运维工作负载，而且将需要监测的服务数量增加了几十倍。
还有一大堆编排/反编排进出其他服务的数据所需要的代码要编写；虽然代码数量通常不是很多，但是总是存在着危险情况。
开销：所有这些不同的数据存储区、数据转换和网络调用随带相当庞大的开销。就个人而言，我发觉改用微服务后，速度大幅下降，大约只有原先的十分之一。
数据隔离：由于现在你的所有数据驻留在不同的数据存储区，就需要负责数据之间的关系。原本是单一整体式应用程序中一个简单的级联删除，现在成了依赖、调用和验证之间错综复杂的关系网。这跟你使用非关系数据存储区几乎如出一辙，所以如果你在这方面有经验，又善于管理，才不会有任何问题。
正如我们上面所见，微服务具有一些相当显著的优点，不过也存在重大缺点。就项目规模而言，大大小小的项目都会得益于更整洁的架构和每个服务更小的代码库，但所有项目也都会受到数隔离和复杂性带来的不利影响。
小规模的项目受到开销的影响会特别大，但是大规模项目会从可扩展性和独立部署受益匪浅，因为微服务有望在为其堆栈添加处理能力，以满足更大工作负载的需求方面提供灵活性和很大的活动余地。
鉴于上述情况，似乎很清楚：小规模项目至少会得益于微服务架构。然而，它们仍能够获得更整洁架构和更小代码库带来的好处，对不对？
别那么快下结论。没有什么阻止得了单一整体式应用程序同样获得微服务的这些好处，同时又享受单一整体式架构的种种好处。实际上，这正是架构完善的单一整体式应用程序应该采用的结构：半独立的模块或代码库，并借助明确定义的接口。可问题在于，这需要一套规范，而基于微服务的架构在系统层面执行了这套规范。
因而，问你自己和团队这样一个问题似乎合情合理：你是否对自己不大放心，以至于为了确保关注点分离（separation of concerns），需要承担部署、实施和速度方面相当大的开销？在大多数情况下，你可以做些其他的事情，比如为模块实施清楚而严格的接口以便彼此联系；制定规则，明确在模块外面可以调用什么、不可以调用什么，如何调用；以及使用工具帮助自己遵守这些规则。
为了帮助你在决定是否需要微服务时理清一大堆错综复杂的问题和考量因素，我制作了一个实用的流程图。如下所示：
这个流程图会回答你在微服务方面的所有问题。
不过也别太当真了。
不要开始时就打算搞微服务，微服务是一种复杂方法，不应该一开始就搞。
综上所述，微服务架构带来的最大优点就是可扩展性，这是其他方法所难以企及的。至于其他每个好处，只要借助一点规范和良好的开发流程，就可以获得。除此之外，如果选择单一整体式方法，你有望获得诸多好处：可靠性、易于部署和监控以及速度快。只要你的单一整体式应用程序采用合适的架构，以后很容易将瓶颈系统分解成独立服务，有望用另外某种语言来改写，如果需要这么做的话。
我真心诚意地告诉各位，别仅仅因为赶时髦的人在搞微服务，你开始时就打算搞微服务。微服务是一种复杂方法，不应该一开始就搞。请享受单一的新应用程序带来的开发简易性和部署灵活性；等到贵公司业务成熟、不断发展壮大，又找不到所需的足够庞大的服务器，再将基础设施的某些部分分解成一个个独立服务，并用HTTP或消息队列连接这些服务。
云头条编译｜未经授权谢绝转载
微服务群欢迎你的加入，群主微信：aclood